Computers have become integral tools used in a wide variety of different applications, such as in finance and commercial transactions, computer-aided design and manufacturing, health care, telecommunication, education, etc. Computers are finding new applications as a result of advances in hardware technology and rapid development in software technology. Furthermore, the functionality of a computer system is dramatically enhanced by coupling these types of stand-alone devices together in order to form a networking environment. Within a networking environment, computer users may readily exchange files, share information stored on a common database, pool resources, and communicate via electronic mail (e-mail) and video teleconferencing.
It is appreciated that all types of information and data can be stored by a commonly shared database. However, when confidential and/or sensitive information is stored on the shared database accessible by thousands of computer users, it may become desirable to control what information specific users have access to within the database.
One conventional approach for providing database access control is to create a read-only account in a database in the following manner. First, a user having unlimited access to the database logs into a write access account of the database. That user then prepares a list of all the tables, synonyms, views, packages, etc. that are available on the database. Next, a new read-only account is created for all of the users of the database. Additionally, within this read-only account, each database user is granted specific access to those particular tables, views, packages and the like of the previously prepared list that they have authority to access. However, there are disadvantages associated with this type of database access control.
For example, one of the disadvantages occurs when a patch (or updated version) of some software is applied to the original account and it added new tables, views, synonyms, packages, etc. to the database. As such, the read-only account does not know about this new information since they are not currently part of the availability list. As such, the availability list is updated in order to reflect the additional, modified and/or changed information of the database. Furthermore, the read-only account is also updated to enable authorized users access to the new and/or updated information. However, as the number of incoming patches becomes more and more numerous which can be common with larger databases, the task of continually updating the availability list and read-only account becomes overly cumbersome and difficult.
Another disadvantage is that in order to access an object in this previously described database access control system, a user who logged into the read-only account (or schema) is not directly in the specific database account whose objects (e.g., tables, views, etc.) the user wants to access. As such, they typically have to write specific commands involving a fully qualified name that precedes each object with the name of the database account to which the object belongs. For example, if a read-only account has been created from an account called “apps”, then to access a table “fnd_diagnostics” from the read-only account, a user cannot just access it as “fnd_diagnostics”. Instead, the user has to specify “apps.fnd_diagnostics”. This can be cumbersome when utilizing a wide variety of script commands. Additionally, this problem is magnified if the user is running scripts that have been created by somebody else. Typically, when scripts are written, they do not use a fully qualified name because they are excepted to run against the original account or schema. Therefore, in order to run these type of scripts, they are modified and each object has to be fully qualified. This type of maintenance can become overly burdensome.
The present invention may address one or more of the above issues.